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1.  SCOPE  AND  PURPOSE 

This  specification  describes  the  Protocol  Test  System  and  the  program 
functions  of  the  Telnet  Remote  Driver  (RD).  Section  2,  "The  Protocol  Test 
System,"  summarizes  the  testing  procedures  used  by  the  Protocol  Test  System. 
Section  3  on  "Remote  Driver  Design  and  Protocol  Testing"  contains  guidelines 
for  developing  a  Telnet  RD  on  a  host  where  an  implementation  under  test  (IUT) 
resides.  The  role  of  the  Telnet  RD  in  protocol  testing  is  also  defined. 

It  should  be  noted  that  vendors  of  Telnet  User  IUTs  need  to  provide  a 
full  service  remote  driver.  When  only  a  Server  implementation  is  to  be 
tested,  the  driver  is  reduced  in  scope.  Appendix  A  describes  this  reduced 
driver. 


■ 


2.  THE  PROTOCOL  TEST  SYSTEM 

2.1  TEST  TOOLS 

The  major  components  of  the  Protocol  Test  System  are: 

o  The  Test  Scenario  Language  —  To  enable  a  tester  to  specify 
standardized  scripts; 

o  The  Scenario  Language  Compiler  and  Libraries  —  To  produce  code  for 
automated  testing; 

o  The  Protocol  Reference  Incrementation  —  To  define  standard 
functions  for  the  protocol  being  tested;  and 

o  The  Drivers  —  Central,  Surrogate,  Slave,  and  Remote  —  To  execute 
tests  and  to  provide  conmunications  links. 

This  test  system  causes  an  IUT  to  perform  peer  protocol  exchanges  with 
a  reference  implementation  at  the  Protocol  Test  System  site.  To  generate 
reproducible  results,  a  script  controls  the  driver  that  controls  each  IUT 
through  its  upper  level  interface.  A  complete  test  executes  several  scenarios 
of  prescribed  actions  that  exercise  one  or  more  protocol  features. 

2.2  GENERAL  REQUIREMENTS  OF  THE  CENTRAL,  SURROGATE,  SLAVE,  AND 
REMOTE  DRIVERS 

The  Central  Test  Driver  (CTD) ,  which  coordinates  and  monitors  protocol 
testing,  combines  the  Surrogate  and  Remote  implementation.  The  Surrogate 
Driver  provides  the  transport  mechanism  between  the  CTD,  the  Slave,  and  the 
Remote  Drivers. 


The  Slave  Driver  passes  comnands  from  the  CTD  to  the  protocol  reference 
implementation,  and  sends  back  responses  from  the  reference  to  the  CTD.  It 
also  executes  driver  commands  received  from  the  CTD.  In  a  similar  manner,  the 
Remote  Driver  executes  driver  commands  from  the  CTD.  Such  commands,  however, 
control  the  RD  itself  and  do  not  affect  the  ILTT's  state,  nor  do  they  refer  to 
IUT  actions.  The  RD's  primary  role  is  communicating  CTD  protocol  primitives 
and  IUT  responses  over  the  network. 


3.  REMOTE  DRIVER  DESIGN  AND  PROTOCOL  TESTING 


The  following  sections  describe  the  Remote  Driver  design  and  explain 
how  all  drivers  interact  to  conmunicate  protocol  commands  or  responses  in  lab 
testing. 

3.1  THE  COMMAND  CHANNEL 

All  drivers  except  the  RD  reside  at  the  Protocol  Test  System  site.  The 
Remote  Driver  operates  as  a  background  process  using  a  Transport  protocol 
level  connection,  which  links  the  RD  at  a  remote  site  with  the  laboratory 
drivers  and  the  reference  and  IUT  protocols. 

To  set  up  the  command  channel,  the  RD  sets  up  a  passive  listen  on  a 
well-known  port  and  waits  for  the  Surrogate  Driver  to  perform  an  active  open 
on  that  port.  The  command  channel  is  ready  when  the  Transport  connection  to 
the  Remote  and  Slave  Drivers  has  been  established,  and  all  drivers  have 
initiated  communications  with  their  respective  protocols.  Figure  1  is  a 
diagram  of  connection  establishment,  and  Table  1  below  gives  destinations  and 
port  numbers. 


Table  1.  Destinations  and  Port  Numbers 


Destination 

Port  Number 

RD  Passive  Open  Port 

1202 

for  User  Testing 

IUT  Server  Telnet  Passive 

23 

Open  Port 

RD  Passive  Open  Port 

1203 

for  Server  Testing 
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FLOW  OF  COMMANDS 


Packets  containing  protocol  command  codes  travel  over  the  command 
channel  from  the  Central  Driver,  through  the  Surrogate  Driver,  to  the  Slave 
and  Remote  Drivers  (Figure  2,  and  Table  3).  The  Slave  and  Remote  Drivers 
translate  these  codes  into  the  appropriate  commands,  then  issue  the  commands. 
Similarly,  responses  from  the  reference  and  IUT  protocols  are  received  by  the 
Slave  and  Remote  Drivers  and  forwarded  over  the  command  channel  to  the 
Surrogate  and  Central  Drivers.  The  Central  Driver  (CTD)  determines  from  the 
combined  test  responses  whether  the  IUT  has  functioned  properly  and  reacts 
accordingly  —  by  taking  the  next  appropriate  action  in  the  testing  process  - 
and  the  flow  of  corrmands  is  repeated. 


Transport  Connection 

Transport  Connection 
(background  process) 

Interprocess 

Communication 


Figure  1.  Connection  Establishm 
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3.3  INPUTS  AND  OUTPUTS 

Data  is  transmitted  from  the  testing  facility  and  to  the  DCA  Laboratory 
in  blocks  called  packets.  The  laboratory  implementation  of  the  Remote  Driver 
uses  a  PAD  (Packet  Assembler/Disassembler)  function  to  control  the  input  and 
output  of  such  packets. 

The  Remote  Driver  must  be  able  to  send  one  of  three  packets:  an  ACK 
(Acknowledgment),  a  NAK  (Negative  Acknowledgment),  or  a  data  packet  containing 
either  protocol  responses  or  driver  command  results.  Figure  3  shows  the 
generic  format  of  the  data  packet;  Figure  D.2  in  Appendix  D  defines  a  data 
packet  in  C  syntax. 


3.3.1  The  Control  Flag  Field 


A  single  octet  contains  the  control  flag,  which  indicates  by  bit 
position  how  the  Remote  Driver  should  interpret  the  rest  of  the  data  packet. 
The  bit  positions  are  in  ascending  order  from  right  to  left,  as  in  a  Digital 
(Digital  Equipment  Corporation)  VAX.  Figure  4  diagrams  the  bit-ordering 
scheme. 


Control  Flag: 


< - 1  byte - > 


|  7  6  5  4  3  2  1  0  | 

l_J_l _ I _ I _ ! _ I _ I _ I 

bit  positions 

Figure  4.  The  Bit  Order  of  a  Byte 

Table  2  summarizes  the  configuration  of  bit  positions  in  the  control 
flag.  Oily  bit  positions  0,  1,  and  2  are  used.  The  RD  sets  the  bit  in  posi¬ 
tion  0  to  one  (1)  to  indicate  that  an  ACK  packet  is  being  sent.  A  zero  (0)  in 
this  position  indicates  a  NAK.  If  the  RD  sets  the  bit  in  position  1,  then  a 
data  packet  (as  opposed  to  an  ACK/NAK  packet)  is  being  sent.  Setting  the  DATA 
bit  in  a  packet  could  signal  either  that  the  RD  is  sending  a  protocol  re¬ 
sponse,  or  that  it  is  sending  the  results  of  one  of  its  own  driver  operations. 
The  bit  in  position  2  of  the  first  octet  of  each  data  packet  sent  by  the  CTD 
determines  whether  the  packet  contains  a  protocol  or  a  driver  command. 


Table  2.  Bit  Positions  in  the  Control  Flag 


Bit  Position 

Remote — >Central 

Central — >Remote 

0 

ACK  =  1 

NAK  =  0 

unused 

1 

data  =  1 

unused 

2 

unused 

protocol  conmand  =  1 
driver  comrand  =  0 

3-7 

unused 

unused 

\ 

s 

\ 

t 

* 

k 

k 

*1 

; 


Error  flags  will  explain  the  nature  of  an  error  occurring  at  the  Remote 
Driver.  Because  error  codes  are  not  yet  implemented,  the  Protocol  Test  System 
makes  no  attempt  to  interpret  this  field. 

3.3.3  The  Primitive  Code  Field 

The  primitive  code  field  can  be  interpreted  in  one  of  two  ways  — 
either  as  a  protocol  primitive  code  or  as  a  driver  primitive  code.  A 
primitive  in  this  sense  means  a  conmand  that  describes  some  action  within  the 
protocol  or  the  driver. 

3. 3. 3.1  The  Protocol  Primitive  Codes 

If  the  control  flag  indicates  a  protocol  conmand  (i.e.,  the  bit  in 
position  2  is  set  to  1),  then  the  Remote  Driver  must  translate  the  integer  in 
the  code  field  to  its  corresponding  protocol  primitive  according  to  the 
descriptions  and  the  code  numbers  in  Table  3.  What  form  of  data  the  RD  sends 
to  the  protocol  IUT  depends  on  the  IUT's  User  Interface,  but  the  RD  must 
include  this  translation  capability  in  its  function.  To  pass  qualification 
testing,  a  Telnet  IUT  must  be  able  to  perform  all  the  primitive  actions 
described  in  Table  3. 

The  Remote  Driver  determines  whether  arguments  are  associated  with  a 
primitive  according  to  its  protocol  IDT.  If  arguments  are  required  for  a 
given  primitive,  they  will  be  supplied  in  the  "data"  field  of  the  data  packet. 
If  such  arguments  are  required  but  not  supplied,  then  an  error  condition 
occurs  and  the  RD  must  NAK  that  packet. 


The  RD  can  determine  whether  the  required  arguments  are  present  by 
reading  the  "num_bytes"  field,  which  tells  how  many  bytes  of  character  ASCII 


r 


R 


£ 
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Table  3.  Protocol  Primitive  Commands,  Number  Codes,  and  Arguments, 
with  Consequent  Telnet  IUT  Action  (Page  1  of  2) 


Primitive  j 

j 

(No.  Code)  | 

1 

Argument 

i 

Telnet  IUT  Action 

GA  (0) 

Causes  the  IUT  to  send  a  go-ahead 
cormand  ( IAC  GA) . 

IP  (1) 

— 

Causes  the  IUT  to  send  an  interrupt 
process  conmand  (IAC  IP). 

AO  (2) 

— 

Causes  the  IUT  to  send  an  abort  output 
conmand  ( IAC  AD) . 

A YT  (3) 

— 

Causes  the  IUT  to  send  an  Are-You-There 
cormand  ( IAC  AYT ) . 

EC  (4) 

— 

Causes  the  IUT  to  send  an  erase  character 
conmand  ( IAC  EC ) . 

EL  (5) 

— 

Causes  the  IUT  to  send  an  erase  line 
conmand  ( IAC  EL) . 

SYNCH  (6) 

— 

Causes  the  IUT  to  send  a  Telnet  "synch" 
signal.  (See  MIL-STD-1782,  p.  9.) 

NOP  (9) 

— 

Causes  the  IUT  to  send  a  no-op 
ccrrmand  ( IAC  NOP ) . 

DO  (10) 

DOtrr  (11) 

WILL  (12) 

WONT  (13) 

option 

option 

option 

option 

Causes  the  IUT  to  send  the  indicated 
negotiation  conmand.  (Negotiation 
commands  are  DO,  DONT,  WILL,  WDNT. )  The 
option  negotiated  is  sent  as  an  ASCII 
string  as  the  first  argument.  These 
strings  are  indicated  in  Table  4. 

STATUS  (14) 

— 

Causes  the  IUT  to  request  status 

information  (if  negotiated)  from  the 
reference  implementation. 


^  1  ^lu.lui  iu.ui^v^  ¥*J9JX*J)  II  fMWI  iwiimij  I.I.1JAJJ1FJ  !■.  ■  ju  ,■,!  1 ,1  RUAI.I.I.I  UAUAU  [•. 
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Table  3.  Protocol  Primitive  Conmands,  Number  Codes,  and  Arguments, 
with  Consequent  Telnet  ILTT  Action  (Page  2  of  2) 


Primitive 

(No.  Code) 


Argument 


Telnet  ILTT  Action 


OPEW  (15) 


host-name 

port-number 


Requests  the  ILTT  to  open  a  connection 
to  the  indicated  host  and  port.  The  port 
number  is  optional.  Both  arguments  are 
represented  in  ASCII  form. 


CLOSE  (16) 


Closes  current  session. 


CM  (17) 


Causes  the  IUT  to  send  a  data  mark 
cormand  ( IAC  DM) . 


BRK  (18) 


Causes  the  ILTT  to  send  a  break  command 
(IAC  BRK). 


'M-\'  -•  .v.y.vi  av  v.v 


WPS! 


Table  4.  Option  Strings  Sent  As  Data  with  Negotiation 
Commands 

'  i 

|  "BINARY" 

I  I 

I  "ECHO"  | 

I  I 

"SUPPRESS  GO  AHEAD"  j 

I  I 

|  "STATUS"  | 

I  I 

"TIMING  MARK" 


3. 3. 3. 2  The  Driver  Primitive  Codes 


If  the  control  flag  indicates  a  driver  cormand  (the  bit  in  position  2 
is  set  to  zero),  the  Remote  Driver  must  translate  the  integer  contained  in  the 
code  field  to  its  corresponding  driver  primitive  (Table  5).  The  RD  then 
performs  the  appropriate  action,  as  specified  in  the  following  sections. 

Table  5.  The  Driver  Primitives 


Code  |  Action 


0  |  -  Kill  the  Remote  Driver  process. 

1  j  -  Send  associated  data  to  the  IUT. 


3. 3. 3. 2.1  The  KILL  Driver  Primitive.  If  the  Remote  Driver  interprets  a 
driver  primitive  code  of  0,  then  after  ACKing  the  driver  primitive  packet,  the 
process  must  find  sane  way  to  terminate  itself.  No  other  action  is  necessary. 
The  Remote  Driver  is  not  responsible  for  conducting  a  graceful  shutdown  of  the 
protocol;  it  is  the  responsibility  of  the  Central  Driver  to  cause  Telnet  to 
quit.  The  RD  also  is  not  required  to  shut  itself  down  gracefully,  although 
this  action  is  encouraged. 

3. 3. 3. 2. 2  The  DATA  Driver  Primitive.  If  the  Remote  Driver  receives  a  driver 
primitive  code  of  1,  indicating  the  DATA  conmand,  then  after  ACKing  the  driver 
primitive  packet,  the  RD  must  send  the  text  portion  of  the  data  packet  to  the 
IUT  as  data. 

An  octal  15  <015>  in  the  data  stream  is  to  be  interpreted  as  a 
carriage  return.  An  octal  15  followed  by  an  octal  12  <15><12>,  is  to  be 
interpreted  as  a  newline. 


3 . 4  ACK/NAK  PACKETS 


The  Remote  Driver  is  required  to  acknowledge  the  receipt  of  every 
driver  or  protocol  command  (ACK  =  positive  acknowledgment;  NAK  =  negative 
acknowledgment).  When  it  is  able  to  read  and  interpret  a  packet  from  the  TCP 
connection,  the  FID  sends  an  ACK  packet.  If  it  detects  an  error,  however,  the 
Remote  Driver  responds  with  a  NAK  packet.  The  F?D  also  sends  a  NAK  packet  if 
read  is  successful  but  a  code  is  unknown,  or  some  other  field  is  in  error. 

The  following  values  indicate  ACK  or  NAK  packets: 

ACK  -  code:  0 

cntl_flag:  bit  position  0  set  to  one  (1) 
bit  position  1  is  unused 

bit  position  2  set  to  one  (1)  if  protocol  conmand, 

to  zero  (0)  if  driver  conmand 

numby  tes :  0 

data :  enpty 

NAK  -  code:  0 

cntl_flag:  bit  position  0  set  to  zero  (0) 
bit  position  1  is  unused 

bit  position  2  set  to  one  (1)  if  protocol  command, 

to  zero  (0)  if  driver  conmand 

num_by tes :  0 

data:  enpty 


Li 


3.5  TIMING 

A  Remote  Driver  has  no  intrinsic  timing  constraints,  but  it  should  not 
add  considerably  to  a  protocol  IUT's  response  time.  For  example,  if  the  CTD 
does  not  receive  a  data  packet  within  the  time  specified  in  a  script,  then  a 
timeout  condition  will  occur.  Such  a  condition  could  cause  an  IUT  to  fail  the 
test. 

3.6  FLEXIBILITY 

Although  drivers  have  no  special  flexibility  requirements,  adaptable 
hardware  and  software  enhances  their  operation  and  expandability.  In  the  next 
phase  of  protocol  testing,  drivers  may  need  to  command  passive  recorders  or 
other  devices. 


». 
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APPENDIX  A 

Remote  Driver  for  Server  Telnet  IUT 


In  the  case  of  Server  Telnet  implementations,  the  IUT  vendor  need  not 
provide  a  full  service  IUT  remote  driver.  What  is  required  from  the  IUT 
vendor  is  a  program  that  is  executed  by  the  reference  User  Telnet  in  the 
Server  Telnet  session.  This  program  acts  like  a  simplistic  IUT  driver  in  two 
respects:  first,  the  Central  Driver  establishes  a  TCP  connection  with  the 
program;  second,  the  program  handles  a  subset  of  commands  the  User  Telnet  IUT 
driver  handles.  This  subset  is  limited  to  the  driver  commands  handled  by  the 
User  Telnet  IUT  driver.  This  program  handles  no  protocol  commands,  and  any 
protocol  command  received  is  NAKed  immediately.  Driver  commands  are  ACKed  or 
NAKed  in  the  usual  manner. 

The  program,  which  is  called  "telnetrsd, ''  sets  up  a  TCP  passive 
connection  on  port  1203.  A  pseudo-code  implementation  follows: 

begin  telnetrsd 

reserve  resources  to  listen  on  port  1203  for  a  TCP 
connection; 

print  string  "driver  Telnet  is  ready"; 

listen  and  wait  on  port  1203  for  a  TCP  connection; 

forever  do 

begin 

if  a  packet  is  received  from  the  central  driver  then 
handle  packet; 

if  characters  are  received  from  the  user  Telnet  then 
send  the  characters  to  the  central  driver  in  a 
data  packet; 


*  -*  WWXWPC  Xmjamvi  mxmwmv  ^saMiaMri  teMMft MWiiv 


A-  2 


Caveat:  The  Central  Driver  should  be  able  to  kill  "telnetrsd"  by  sending  it  a 
"Kill  Remote  Driver"  comnand. 


APREJOIX  B 


APPQOIX  C  -  Glossary 


ACK  (Acknowledgment) 


In  data  transfer  between  devices,  data  is  blocked  into  units  of  a  size 


given  in  each  block's  header.  If  the  received  data  is  found  to  be  without 


errors,  then  the  receiving  device  sends  an  ACK  block  back  to  the  transmitting 


unit  to  acknowledge  receipt.  The  transmitting  device  then  sends  the  next 


block.  If  the  receiving  unit  detects  errors,  however,  it  sends  a  NAK  block  to 


indicate  the  received  data  contained  errors. 


ASCII  (American  Standard  Code  for  Information  Interchange) 


A  standard  code  for  the  representation  of  alphanumeric  information. 


ASCII  is  an  8-bit  code  in  which  7  bits  indicate  the  character  represented  and 


the  8th,  high-order  bit  is  used  for  parity. 


CID  (Central  Test  Driver) 


Digital  (Digital  Equipment  Corporation) 


IAC  (Interpret  As  Conmand) 


Telnet's  escape  charter,  whose  valve  is  255  decimal. 


IUT  ( Inplementation  Under  Test) 


A  given  vendor's  protocol  implementation  and  the  subject  of  the  immediate 

test. 

MIL-SID  (Military  Standard) 

Specification  published  by  the  Department  of  Defense. 

NAK  (Negative  Acknowledgment) 

In  data  transfer  between  devices,  a  NAK  block  is  returned  by  the 
receiving  device  to  the  sending  device  to  indicate  the  preceding  data  block 
contained  errors.  Also  see  ACK. 

packet  switching 

A  method  of  transmitting  messages  through  a  network  in  which  long 
messages  are  subdivided  into  short  packets.  The  packets  are  then  transmitted 
as  in  message  switching. 

PAD  (Packet  Assembler/Disassembler) 

In  this  document,  PAD  refers  to  a  module  of  a  structured  program 
responsible  for  reading  and  writing  data  packets.  Not  to  be  confused  with  the 
other  known  usage,  which  describes  a  device  to  provide  service  to  asynchronous 
terminals  within  an  X.25  network. 

PAR  (Positive  Acknowledgment  and  Response) 


A  simple  communication  protocol  stating  that  every  packet  received  must 
be  either  ACKed  or  NAKed. 

protocol 

A  set  of  rules  governing  the  operation  of  functional  units  to  achieve 
communication. 

TCP  (Transmission  Control  Protocol) 

The  DoD  standard  connection-oriented  transport  protocol  used  to  provide 
reliable,  sequenced,  end-to-end  service. 

Telnet 

The  DoD  interim  standard  Virtual  Terminal  Protocol  for  the  flexible 
attachment  of  remote  terminals  to  host  computer  systems  over  the  network. 


APFHOIX  D  -  Exanples  of  Remote  Driver  Implementation  in  UNTX/C 

D.l  (XMNECTICN  ESTABLISHMENT 

The  Remote  Driver  must  be  able  to  establish  interprocess  cormunication; 
i.e.,  to  read  and  write  a  data  stream  from  a  Transport  (TCP)  socket  or  from 
the  Telnet  IUT.  Although  the  method  of  interprocess  communication  is  not 
specified  for  the  Renote  Driver,  a  description  of  how  a  Remote  Driver  is 
implemented  at  the  Protocol  Test  System  site  may  be  helpful.  (See  Figure 
D.l. ) 

The  Protocol  Test  System  runs  in  a  UNIX  4.2  BSD  environment.  The  Remote 
Driver  is  implemented  in  C  language,  which  provides  access  to  several 
interprocess  cortmunication  system  calls  (e.g.,  fork,  socket,  bind,  pipe, 
listen,  and  accept  system  calls). 

Specifically,  the  IUT  process  is  activated  by  the  Remote  Driver  process 
using  the  fork  system  call.  This  forking  causes  a  parent-child  relationship 
to  be  formed  between  the  two  processes.  Each  process  then  determines  whether 
it  is  the  child  or  the  parent.  If  the  process  is  the  parent,  then  it  exits. 

In  effect,  this  action  leaves  the  child  process  running  as  a  background 
process.  This  background  process  then  sets  up  the  TCP  socket  connection  by 
listening  passively  on  the  TCP  port  specified  in  Table  1. 


After  the  TCP  connection  is  established,  the  Remote  Driver  sets  up 
communication  with  the  iur  by  forking  another  process  and  setting  up  inter¬ 
process  communication  through  the  use  of  the  pipe  system  call.  Once  the  pipes 
are  established,  the  input/output  of  the  two  processes  can  be  manipulated  so 
that  the  two  processes  end  up  communicating  with  each  other.  Since  the  parent 
and  child  processes  are  exactly  the  same  (except  for  process  identification 
numbers)  and  would  be  useless  talking  to  themselves,  the  protocol  IUT  is 
overlayed  onto  the  child  process  using  the  exec  system  call. 


When  this  procedure  is  successfully  completed,  the  Remote  Driver  — 
running  as  a  background  process  —  is  receiving  and  sending  data  over  the  TCP 
connection  on  one  side,  and  sending/  receiving  data  to/from  the  protocol  IUT  on 
the  other  side.  (See  Figure  1.) 


D. 2  A  PAD  FUNCTION 


A  Packet  Assembler/Disassembler  (PAD)  function  is  useful  for  implementing 
a  Remote  Driver.  Because  the  two  basic  functions  of  receiving  and  transmitting 
packets  are  performed  repeatedly,  it  may  be  wise  to  modularize  them.  When  the 
Remote  Driver  reads  data  from  the  command  channel,  it  must  be  able  to  inter¬ 
pret  the  bytes  correctly.  In  a  UNIX/C  implementation,  the  method  used  to 
achieve  this  result  is  to  load  the  data  into  a  data  structure  where  distinct 
fields  can  be  declared.  In  C,  this  is  the  "struct"  declaration.  Each  collec- 


/*  CONNECTION  ESTABLISHMENT 

/*  spawn  IUT  process,  and  */ 

/*  put  this  process  into  background...  */ 
/*  parent  returns  pid;  child  returns  0  */ 
if  (  (fork_stat  =  forkO)  >0)  /*  pid  >  0 

exitO;  /*  so,  if  parent,  then  exit.  */ 

/*  else,  this  is  child,  so  continue  V 

pp  =  getprotobyname ( "tcp” ) ;  /*  4.2  BSD  system  call  */ 

while  ( (s  =  socket (AF_INET,  SOCK_STREAM,  pp- >p_proto ) )  <  0) 

{  if  (errno  !=  0) 

{  perror ("Telnet_SD:  socket"); 
sleep(l) ; 

} 

} 

sin.sin_port  =  sp->s_port;  /*  see  port  #  */ 

/*  bind  name  to  socket  */ 
while  (bind(s,  (cadd_t)&sin,  sizeof(sin),  0)  <  0) 

{  perror ("Telnet_SD:  bind"); 
sleep (10) ; 

} 

listen (s,  10);  /*  passive  listen  on  socket  */ 

/*  accept  connection  V 

s2  =  acceptts,  (caddr_t)&from,  &fromlen) ; 

,/*  set  up  pipes  */ 

if  (pipe(fdl)  <  0) 
return (-1) ; 
if  (pipe(fd2)  <  0) 
return (-1) ; 
injoipe  =  fdl [0 1 ; 
outjpipe  =  fd2[l] ; 

if  (forkO  ==  0)  /*  if  child  then  execute  the  following  V 

{  close  (0);  /*  close  std  input 

if  (dup2  (fd2[0],  0)  <  0  )  /*  open  READ  side  of  pipe 

perror  ("dup2"); 

close  (l);  /*  close  std  output 

if  (dup2  (fdl [11,  1)  <  0)  /*  open  WRITE  side 

execl  ( "/usr/iut/iut_telnet" ,  " iut_telnet" ,  ”-v",  "-n",  NULL); 

} 


Figure  D.l.  Outline  of  Connection  Establishment  in  4.2  BSD  UNIX/C 


4096 


#de  f ine  MAX_TEXT_LEN 
struct  remotejpack  { 

char  cntl_flag; 

char  err_flag; 

int  code; 

int  num_by tes ; 

int  reserved; 

char  text ( MAX_TEXT_LEN ) ; 

} ; 

Figure  D.2.  The  C  Syntax  Format  of  the  Data  Packet 

The  reception  mode  of  the  PAD  function  reads  data  and  "packets"  the  data. 
The  PAD  accomplishes  this  task  by  reading  the  first  14  bytes  of  data  from  the 
input  stream.  This  first  14  bytes  is  effectively  the  header  of  the  data 
packet.  It  contains  all  the  information  needed  to  process  the  packet, 
including  the  integer  in  the  "num_bytes"  field  that  indicates  the  number  of 
bytes  of  character  text  to  follow,  if  any. 

The  transmission  mode  of  the  PAD  function  depackets  the  data  and  sends  it 
over  the  conmunication  channel.  The  PAD  acconplishes  this  task  by  reading  the 
header  of  the  packet  and  writing  the  information  into  a  memory  space  allocated 
for  a  large  character  string.  The  size  is  equal  to  4096  bytes  —  the  maximum 
text  size  —  plus  14  bytes  for  the  header  information.  If  the  text  size  is 
less  than  the  maximum,  then  only  that  much  need  be  written.  The  Remote  Driver 
must  transmit  the  data  as  a  normal  byte  stream.  If  the  input  data  stream  is 
correctly  packeted  into  a  data  structure,  then  interpretation  of  the  fields  in 
the  packet  should  become  clearer  and  less  susceptible  to  error.  An  example  of 
a  PAD  implemented  in  C  is  given  in  Figure  D.3. 


#def me  HEADER_SIZE  14 

#def ine  MAX_TEXT_LEN  4096 

#def  ine  MAX_PACK_LEN  HEADER_S  I  ZE+MAX_TEXT_L£M 

send  _packet( packet, sock)  /*  packet  disassembler 

struct  remote_pack  * packet; 
int  sock; 

{  register  int  i; 

char  send_buf fer (MAX_PACK_LEN  ] ; 

send_buffer [0]  =  packet- >cntl_f lag; 
send_buffer [ 1 j  =  packet->err_f lag; 

*((int  *) (send_buffer+2) )  =  packet->code; 

*((int  *) (send_buffer+6) )  =  packet- >num_bytes; 

*((int  *) (send_buffer+10) )  =  packet- >reserved; 

for ( i=0 ; i<packet->num_bytes ; i++ ) 

send_buf fer [ i+14 1  =  packet->text [ 1 J ; 

/*  send  the  packet 
return (write (sock,  sendbuffer, 

packet- >num_bytes+HEADER_S I ZE) ) ; 


r ecv_packet ( packet , sock ) 
struct  remote_pack  *packet; 
int  sock; 


/*  packet  assembler 


char  recv_buffer (HEADEE_SIZEj ; 
int  result; 

/*  read  the  header  */ 

if  (  (result  =  read(sock,  recv_buffer,  HEADER_SIZE) )  != 

HEAECR  SIZE) 

{ 

return  (result); 

} 

packet- Xntl_f lag  =  recv_buffer  (0) ; 
packet- >err_f lag  =  recv_buffer [ 1 ] ; 
packet- >code  =  *((int  *)  ( recv_buffer+2) ) ; 

packet- >num_bytes  =  *((int  *)  (recv_buffer+6) ) ; 
packet->reserved  =  *((int  *)  (recv_buffer+10) ) ; 

/*  read  the  text  */ 

i f  { packet- >num_bytes ) 

r 

L 

if (read (sock,  packet- >text,  packet- >num_bytes )  != 

packet- >num_by tes ) 

return (-1) ; 


return(O) ; 


Figure  D.3.  A  Packet  Assembler/Disassembler  in  C 


